When a task is enqueued into or dequeued from the ready queue, the
bitmap that indicates the ready queue state should be updated.

These three marcos can be used in mo_task_dequeue() and
mo_task_enqueue() APIs to improve readability and maintain
consistency.

This commit introduces two helper functions for intrusive list
usage, where each task embeds its own list node instead of relying
on per-operation malloc/free.

The new APIs allow the scheduler to manipulate ready-queue nodes
directly:

 - list_pushback_node(): append an existing node to the end of the
   list (before the tail sentinel) without allocating memory.

 - list_remove_node(): remove a node from the list without freeing
   it, allowing the caller to control the node's lifetime.

These helpers will be used by the upcoming O(1) scheduler
enqueue/dequeue paths, which require embedded list nodes stored in
tcb_t.

This commit introduces a new API, sched_migrate_task(), which enables
migration of a task between ready queues of different priority levels.

The function safely removes the task from its current ready queue and
enqueues it into the target queue, updating the corresponding RR cursor
and ready bitmap to maintain scheduler consistency. This helper will be
used in mo_task_priority() and other task management routines that
adjust task priority dynamically.

Future improvement:
The current enqueue path allocates a new list node for each task
insertion based on its TCB pointer. In the future, this can be optimized
by directly transferring or reusing the existing list node between
ready queues, eliminating the need for an additional malloc() and free()
operations during priority migrations.

This change refactors the priority update process in mo_task_priority()
to include early-return checks and proper task migration handling.

- Early-return conditions:
  * Prevent modification of the idle task.
  * Disallow assigning TASK_PRIO_IDLE to non-idle tasks.
  The idle task is created by idle_task_init() during system startup and
  must retain its fixed priority.

- Task migration:
  If the priority-changed task resides in a ready queue (TASK_READY or
  TASK_RUNNING), sched_migrate_task() is called to move it to the queue
  corresponding to the new priority.

- Running task behavior:
  When the current running task changes its own priority, it yields the
  CPU so the scheduler can dispatch the next highest-priority task.

This commit introduces the system idle task and its initialization API
(idle_task_init()). The idle task serves as the default execution
context when no other runnable tasks exist in the system.

The sched_idle() function supports both preemptive and cooperative
modes. In sched_t, a list node named task_idle is added to record the
idle task sentinel. The idle task never enters any ready queue and its
priority level cannot be changed.

When idle_task_init() is called, the idle task is initialized as the
first execution context. This eliminates the need for additional APIs
in main() to set up the initial high-priority task during system launch.
This design allows task priorities to be adjusted safely during
app_main(), while keeping the scheduler’s entry point consistent.

When all ready queues are empty, the scheduler should switch
to idle mode and wait for incoming interrupts. This commit
introduces a dedicated helper to handle that transition,
centralizing the logic and improving readbility of the
scheduler path to idle.

Prepare for O(1) bitmap index lookup by adding a 32-entry De Bruijn
sequence table. The table will be used in later commits to replace
iterative bit scanning. No functional change in this patch.

Implement the helper function that uses a De Bruijn multiply-and-LUT
approach to compute the index of the least-significant set bit in O(1)
time complexity.

This helper is not yet wired into the scheduler logic; integration
will follow in a later commit. No functional change in this patch.

Previously, sched_wakeup_task() was limited to internal use within
the scheduler module.
This change makes it globally visible so that it can be reused
in semaphore.c for task wake-up operations.

Previously, mo_sem_signal() only changed the awakened task state
to TASK_READY when a semaphore signal was triggered. In the new
scheduler design, which selects runnable tasks from ready queues,
the awakened task must also be enqueued for scheduling.

This change invokes sched_wakeup_task() to perform the enqueue
operation, ensuring the awakened task is properly inserted into
the ready queue.

Previously, mo_task_spawn() only created a task and appended it to the
global task list (kcb->tasks), assigning the first task directly from
the global list node.

This change adds a call to sched_enqueue_task() within the critical
section to enqueue the task into the ready queue and safely initialize
its scheduling attributes. The first task assignment is now aligned
with the RR cursor mechanism to ensure consistency with the O(1)
scheduler.

Previously, the scheduler iterated through the global task list
(kcb->tasks) to find the next TASK_READY task, resulting in O(N)
selection time. This approach limited scalability and caused
inconsistent task rotation under heavy load.

The new scheduling process:
1. Check the ready bitmap and find the highest priority level.
2. Select the RR cursor node from the corresponding ready queue.
3. Advance the selected cursor node circularly.

Why RR cursor instead of pop/enqueue rotation:
- Fewer operations on the ready queue: compared to the pop/enqueue
  approach, which requires two function calls per switch, the RR
  cursor method only advances one pointer per scheduling cycle.
- Cache friendly: always accesses the same cursor node, improving
  cache locality on hot paths.
- Cycle deterministic: RR cursor design allows deterministic task
  rotation and enables potential future extensions such as cycle
  accounting or fairness-based algorithms.

This change introduces a fully O(1) scheduler design based on
per-priority ready queues and round-robin (RR) cursors. Each ready
queue maintains its own cursor, allowing the scheduler to select
the next runnable task in constant time.

Previously, when all ready queues were empty, the scheduler
would trigger a kernel panic. This condition should instead
transition into the idle task rather than panic.

The new sched_switch_to_idle() helper centralizes this logic,
making the path to idle clearer and more readable.

Replace the iterative bitmap scanning with the De Bruijn multiply+LUT
method via the new helper. This change makes top-priority selection
constant-time and deterministic.

The idle task is now initialized in main() during system startup.
This ensures that the scheduler always has a valid execution context
before any user or application tasks are created. Initializing the
idle task early guarantees a safe fallback path when no runnable
tasks exist and keeps the scheduler entry point consistent.

This change sets up the scheduler state during system startup by
assigning kcb->task_current to kcb->harts->task_idle and dispatching
to the idle task as the first execution context.

This commit also keeps the scheduling entry path consistent between
startup and runtime.

Previously, both mo_task_spawn() and idle_task_init() implicitly
bound their created tasks to kcb->task_current as the first execution
context. This behavior caused ambiguity with the scheduler, which is
now responsible for determining the active task during system startup.

This change removes the initial binding logic from both functions,
allowing the startup process (main()) to explicitly assign
kcb->task_current (typically to the idle task) during launch.
This ensures a single, centralized initialization flow and improves
the separation between task creation and scheduling control.